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Empezar con POV (parte II) 



A pesar de que «POV» tiene una presencia casi constante en 
Rendermania, cada vez es mayor el numero de lectores que declaran en 
sus cartas no entender muchos de los articulos dedicados a este 
programa, e incluso hemos recibido misivas donde se nos pregunta 
"<i,que es POV?". Esta aparente paradoja tiene una facil explicacion. 
Hace ya casi ano y medio explicamos los conceptos basicos de este 
raytracer y desde entonces no hemos vuelto a hablar de ellos, con lo cual 
los lectores mas recientes no pueden seguir los articulos mas complejos. 
Por esta razon, este mes continuaremos repasando los temas basicos 
como preludio a otros asuntos mas complejos como la creacion de 
texturas procedurales o la animacion. 



ay que aclarar, sin 

H embargo, que los 
presentes articulos 
no van a ser una 
repeticion del mi- 
crocurso que dedi- 
camos a «POV» en los numeros y 1 
de Rendermania. En aquella ocasion 
nos centramos en gran medida en las 
sentencias de creacion de objetos del 
lenguaje escenico de «POV» y en co- 
mo modelar con ellas. Esta vez, por 
el contrario, obviaremos casi toda es- 
ta parte, asumiendo que la mayon'a de 
los usuarios van a trabajar con mode- 
los importados construidos desde mo- 
deladores graficos. Asi pues estudia- 
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reraos como manipular estos modelos 
importados desde POV y como crear 
texturas procedurales, emplear los 
efectos de POV, etc. 

Mas sobre #0BJECT, 
#DECLAREE#INCLUDE 

El mes anterior estudiamos un sen- 
cillo ejemplo en el que se utilizaba la 
utilidad de conversion 3ds2pov para 
"traducir" un fichero 3ds al formato 
de POV. Como ya vimos, la utilidad 
proceso el archivo con el modelo de 
«3D Studio» y creo dos ficheros para 
«POV». La malla con la geometria de la 
vaca se guardo en el archivo vaca.inc, 
y otros datos como el color de la vaca, 
la posicion y orientacion de la camara 
y la iluminacion se almacenaron en 
vaca.pov. Por ello puede decirse que, 
mas que un traductor de objetos, 
3ds2pov es un traductor de escenas, 
ya que, salvo por la aplicacion de los 
bitmaps, esta utilidad traduce todos 
los elementos de la escena original de 
«3D Studio* al formato de «POV». Sin 
embargo, aunque gracias a 3ds2pov 
podrfamos limitarnos despues, sin ha- 
cer nada mas, a ordenar el render des- 
de «POV» y aunque esto mismo es 



posible tambien -y de manera mas 
sencilla aun- trabajando con otros 
modeladores (como Rhino), el caso 
es que de esta manera no estan'amos 
aprovechando las posibilidades de 
«POV». Lo ideal es crear los objetos 



desde otros modeladores y exportar- 
los a «POV», desde donde los mani- 
pularemos para crear la escena utili- 
zando el lenguaje escenico. Esto 
resulta menos interactivo que realizar 
todo el trabajo desde un modelador 
visual como «Rhino» o «3D Studio», 
pero tambien presenta importantes 
ventajas que aprenderemos con el 
tiempo y por esta razon habremos de 
seguir estudiando el lenguaje escenico 
de POV. 

Ahora continuaremos estudiando 
diversas maneras de manipular obje- 
tos con el lenguaje escenico. El mes 
anterior vimos con el ejemplo de va- 
ca.pov y vaca.inc que podfamos crear 
una vaca en la escena con la siguiente 
sentencia del archivo vaca.pov: 

#include "vaca.inc" 



Figura 1 



#declare colorpiel=texture{ 
#declare vari=rand(R) 
pigment { color rgb <.10, l-(vari/4), .20> ] 



#declare head=object{#include "headl.inc") // la cabeza del orco 

#declare torax=object{#include "torax.inc"} // su torax 

tdeclare brazo_derecho=object{#include "brazod.inc"} // su brazo derecho 



// la union siguiente define al modelo completo del orco 

union{ 

objectfhead rotate y*45} // la cabeza rota 45 grados 

objectftorax } 

objectfcinturon pigment{MarronClaro}} 



texturejcolorpiel} 
translate <Xpos,35,Zpos> 
} // aquitermina la union 



// todo el conjunto se traslada 
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Esto generaba una vaca en la posi- 
cion definida por la malla guardada en 
el fichero vaca. inc. Para poder crear 
una segunda vaca o para manipular a 
una unica vaca habi'a que utilizar una 
sentencia object como la que sigue: 

object{#include "vaca.inc" transla- 
te<344,0,400>) 

Con la sentencia object se crea una 
especie de contenedor definido por los 
corchetes. Asi, las operaciones de 
transformation espacial que se definan 
dentro de estos corchetes afectaran 
linicamente al objeto contenido por 
ellos. Este detalle -tan parecido a los 
bloques de C- es una parte fundamen- 
tal de la filosoffa de POV y habremos 
de tenerlo en cuenta en la manipula- 
tion de cualquier objeto compuesto 
por otros mas simples (como es el ca- 
so del orco o del guerrero humano). 
Examinemos ahora el ejemplo de la 
Figura 1 (en la pagina anterior). 

En este ejemplo podemos compro- 
bar muchos de los detalles que con- 
forman la filosoffa de «POV». Se trata 
de un extracto de un fichero para crear 
una figura antropomorfica. La prime- 
ra sentencia es un #declare con el que 
se define el identificador "colorpiel" 
como una textura (que luego podn'a 



ser aplicada a un objeto). Despues se 
usan tres #declares para definir tres 
objetos llamados "head", "torax" y 
"brazo_derecho". Asi pues, como po- 
deis ver, podemos usar la sentencia 
#declare no solo para asignar valores 
a variables sino tambien para declarar 
nuevas texturas y objetos. La sintaxis 
para declarar un objeto es: 

#declare identificador=object (sen- 
tencias de definition) 

Luego, para utilizar lo declarado, 
tendremos que usar una linea como: 

object {identificador sentencias} 

Con #declare el objeto definido po- 
dra ser invocado cuantas veces quera- 
mos en la escena usando sentencias 
object. Seguramente el lector se pre- 
guntara por que tenemos que moles- 
tarnos en hacer esto cuando podria- 
mos escribir algo como: 



object(#include "objeto. inc" sen- 
tencias} 

...cada vez que desearamos situar un 
objeto (guardado en otro fichero) en 
la escena. Para responder a esto ima- 
ginad que queremos situar 200 orcos 
en nuestra escena (por ejemplo para 
una batalla). Con ttinclude, «POV» 
tendn'a que leer 200 veces el fichero 
objeto.inc, lo cual seria horriblemente 
lento (sobre todo si objeto.inc es un 
modelo poligonal complejo). En cam- 
bio usando #declare «POV» solo lee- 
ria el fichero una vez, guardaria un 
modelo en memoria asignandolo al 
identificador, y lo emplean'a cada vez 
que el identificador fuese invocado 
con object. Es de suponer que la can- 
tidad total de RAM empleada sera si- 
milar en ambos casos pero #declare es 
mas comodo y mas versatil (como ve- 






Figura 2 




#declare Here=<l,2,3> 






#declare Count=0 


// initialize Count 




union { 






object { Rod translate Here*Count ) 






#declare Count=Count+l 


// re-declare inside union 




object ( Rod translate Here*Count } 






#declare Count=Count+l 


// re-declare inside union 




object ( Rod translate Here*Count } 
} 







Las texturas procedurales son tridimensionales, como puede apreciarse en estas imageries de ejemplo. 
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remos mas adelante). Aunque #decla- 
re nos permite declarer mas cosas 
ademas de variables, objetos y textu- 
ras, por el momento nos contentare- 
mos con esto. 

Un identificador puede tener hasta 
40 caracteres y puede emplear letras 
y numeros (aunque no debe comenzar 
con un numero). Tambien es impor- 
tante recordar que «POV» diferencia 
entre mayiisculas y minusculas por lo 
que el identificador "YuYu" no es lo 
mismo que "yuyu" y tambien habre- 
mos de tener cuidado de no usar co- 
mo identificador ninguna palabra re- 
servada del lenguaje escenico como 
sphere, box u otras similares (consul- 
tad la lista en povray.doc, en el apar- 
tado "Identifiers and Keywords"). 
Hay que tener cuidado con estos dos 
ultimos detalles. 

Las declaraciones pueden colocarse 
en cualquier punto de los ficheros, in- 
cluso dentro de otras sentencias. En la 
Figura 2 tenemos un ejemplo tornado 
de povray.doc 

El trabajo con las variables se basa 
en la facultad que ofrece #declare de 
emplear un valor asignado anterior- 
mente como parte de una nueva decla- 



racion. Sin embargo, hay un caso don- 
de esto no funcionara: si intentamos 
redifinir un identificador como algo 
distinto obtendremos un error en el 
parsing. Asf, si por ejemplo hemos 
definido "hroki" como una textura e 
intentamos redefinirla despues como 
un objeto, obtendremos un error y lo 
mismo sucedera si definimos un iden- 
tificador como un valor e intentamos 
declararlo luego como un vector. 

Uniones 

Pero continuemos con el ejemplo de 
la Figura 1. En el veremos que el ter- 
cer bloque de sentencias comienza 
con la palabra union. Esta sentencia 
se utiliza para crear objetos compues- 
tos por otros mas simples. Su forma 
de uso es similar al de object, pero 
con la diferencia de que podemos me- 
ter varios objetos dentro del bloque 
delimitado por los corchetes. Estos 
objetos no tienen por que ser objetos 
simples ya que una union puede estar 
compuesta tambien por otras uniones. 
La utilidad de las uniones radica en 
que, a efectos practicos, «POV» trata- 
ra como un objeto unico todo lo que 
se halle dentro de los corchetes de una 



de estas sentencias. Esto es muy util 
porque los modelos complejos rara- 
mente suelen estar compuestos por 
una unica pieza. En el caso de nuestro 
orco, por ejemplo, este esta compuesto 
por piezas como los brazos, las pier- 
nas, la cabeza, etc, cuya posicion y 
orientacion nos puede interesar alterar 
individualmente dentro del conjunto 
del modelo. Veamos como funciona: 
la primera sentencia que encontramos 
dentro del bloque de la union es 
objectjhead rotate y*45} 
Esta sentencia indica a «POV» que 
el objeto head ya declarado antes es 
parte de la union. Al no haber ninguna 
orden translate dentro del bloque de 
este object, «POV» situara a head en 
la escena en la misma posicion en que 
este objeto se halla definido. (Head, 
como otros objetos del orco, es un ob- 
jeto poligonal y su posicion inicial 
viene dada por los valores asignados a 
los vertices de su malla). Lo que si te- 
nemos aqui es una transformacion ro- 
tate que hara girar la cabeza 45 gra- 
dos. Como la sentencia rotate esta 
encerrada dentro del bloque contene- 
dor de head, esta transformacion es- 
pacial solo afectara a la cabeza, sien- 
do ignorada por el resto de los objetos 
miembros de la union. 

Esta regla de aislamiento de los blo- 
ques es simple pero esencial y tene- 
mos otro ejemplo de su funciona- 
miento en el tercer miembro de la 
union donde se asigna el color "Ma- 
rronClaro" al objeto "cinturon". (La 
sentencia pigment especifica el color 
de un objeto y normalmente suele ser 
parte de la definition de una textura 
pero, si no vamos a definir otras pro- 
piedades para la textura, podemos uti- 
lizar pigment fuera de texture). Puesto 
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que la sentencia pigment esta dentro 
del bloque de "cinturon", el color in- 
dicado solo se aplicara sobre este ob- 
jeto y no sobre los anteriores. 

Por ultimo fijaos en las dos ultimas 
sentencias escritas dentro de la union. 
Estas sentencias no agregan nuevos 
miembros a la union. La primera es 

texture (colorpiel) 
que aplica una textura ya declarada an- 
teriormente. Pero, ^ donde se aplica es- 
ta textura? Siguiendo las reglas de los 
corchetes podemos adivinar que se 
aplica dentro de la union, es decir, so- 
bre todos los miembros de esta, pero 
^que sucede con el objeto "cinturon"? 
En este caso concrete «POV» ya ha 
asignado una textura a "cinturon" y, 
por tanto no aplicara la "colorpiel". 
Resumiendo: en el caso de las texturas, 
la textura "global" solo se aplicara so- 
bre aquellos miembros de la union que 
no tengan asignada su propia textura. 

Pero, objetara el lector, lo que se ha 
asignado a "cinturon" es un pigmento 
y no una textura. jPues no! Aunque no 
vamos a entrar ahora en demasiados 
detalles acerca de las sentencias de 
construction de texturas, si que dire- 
mos que las texturas "normales" de 
«POV» se definen con sentencias que 
se agrupan en tres apartados diferen- 
ciados: la pigmentation (pigment), las 
sentencias que perturban las normales 
(normal) y las que definen el acabado 
de la superficie (finish). Para cada uno 
de estos apartados «POV» tiene ya 
asignados unos valores por defecto 
(que pueden cambiarse), de manera 
que podemos ahorrarnos escribir la 
declaration completa de una textura 
cuando estamos creando una nueva. 
Asi, en lugar de escribir algo como lo 
que aparece en la Figura 3... 



...podemos limitarnos a escribir, por 
ejemplo: 

pigment{ sentencias que afectan al 
color } 

Pero cuando «POV» encuentra una 
h'nea como la anterior, lo que hace es 
aplicar una textura completa usando los 
valores por defecto para los otros apar- 
tados (lo mismo sucede con normal y 
finish). Por esta razon, en el ejemplo 
anterior la asignacion del pigmento 
"MarronClaro" provoca la asignacion 
completa de una textura de manera que 
en el caso del objeto "cinturon" se ig- 
nore la textura "colorpiel". 

Mas simple aun es el caso de la sen- 
tencia siguiente del ejemplo de la Fi- 
gura 3, donde tenemos una transfor- 
mation espacial. Esta transformacion 
se aplicara sin excepciones sobre tcPI 
dos los miembros de la union. ^.Que 
ocurre entonces, os preguntareis, con 
el miembro head que tiene escrita una 
transformacion dentro de su bloque? 
En este caso se aplicaran las dos. Prjgg 
mero «POV» efectuara la transforma- 
cion particular de head, haciendo rotar 



texture) pigment! sentencias que afectan al color ) 

normalf sentencias que afectan a las normales } 
finish{ sentencias que afectan al acabado } 



> 



la cabeza del orco y luego la union 
completa (el orco) sera trasladada a la 
position resultante al aplicar la tras- 
lacion global. (Y este sera el resultado 
que obtendremos cuando la escena es- 
te lista). Esta regla es identica para 
otros casos mas complejos. Recorde- 
mos un ejemplo muy ilustrativo que 



ya fue incluido en el ntimero 14 de 
Rendermam'a: 

Fijaos en el caso del objeto manod 
(mano derecha). Sobre este objeto se 
aplican primero las transformaciones 
escritas dentro de la union de la que 
forma parte. Despues se le aplican las 
transformaciones de la union de ma- 
yor nivel (el antebrazo) de la que for- 
ma parte la union de la que es miem- 
bro. Y por ultimo se efectuan las 
transformaciones de la union princi- 
pal que es el brazo. Este ejemplo -cu- 
yo correcto funcionamiento quedo 
demostrado con los orcos del numero 
14 de Rendermam'a- demuestra que 
«POV» trata las estructuras de bloques 
procesandolas de dentro a afuera. Esto 
puede ser empleado para simular en 
«POV» estructuras jerarquicas de ob- 
jetos. En este ejemplo tenemos una es- 
tructura de este tipo donde la mano y 
el arma son objetos hijos del antebra- 
TEO, el cual, a su vez, es hijo del objeto 
que va unido al hombro. La utilidad 
de esto radica en que podemos dar 
una transformacion dada a la mano 
pero esta, ade- 
mas, obedecera 
despues prime- 
ro a las trans- 
formaciones 
escritas para el 
antebrazo y 
luego a las se- 
naladas para el 
brazo entero. Al llegar a este punto, 
quiza los pov-adeptos mas novatos se 
sientan ya con fuerzas para afrontar el 
articulo dedicado a este tema en el 
Rendermam'a 14 pero, como este ca- 
so es un poco complejo, os recomen- 
damos que practiqueis con ejemplos 
mas simples. 



Figura 3 
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La sentencia union es muy emplea- 
da tambien por las utilidades de tra- 
duccion, que la utilizan para agrupar 
listas de triangulos de manera que se 
pueda asignar facilmente texturas o 
transformaciones a los objetos forma- 
dos por estas mallas de triangulos. 
Tambien hay que decir que union fue 
disenada en principio como parte de 
la filosofia de modelado de «POV», la 
cual se apoya grandemente en las ope- 
raciones booleanas. Pero por ahora no 
vamos a entrar en ello porque dichas 
operaciones no funcionan con los ob- 
jetos poligonales importados. 

Algo sobre colores y texturas 

Para poder crear una escena en 
«POV» diferente a una imagen abso- 
lutamente negra no basta con crear o 
cargar objetos en el pov-universo y 
encender una fuente de luz dentro de 
este (ademas, claro esta, de situar y 





//brazo derecho 
union{ 

union{object{antebd} 
object{munned} 
//la mano y su arma cogen tambien el giro del antebrazo 
union{object{manod} objectfarma} 
translate<39. 5,-75,-2. 5> 
rotate <rmanodX, rmanodY, rmanodZ> 
translate<-39.5,75,2.5> 
} 

translate<38,-104,-12> 
rotate <rantebdX, rantebdY, rantebdZ> 
translate<-38,104,12> 
} 

objectfbrazod} 
translate<25,-136,-9> 
rotate <rbrazodX, rbrazodY, rbrazodZ> 
translate<-25,136,9> 



} 



orientar una camara). Tambien hay 
que asignar texturas a los objetos 
puesto que de lo contrario no podre- 
mos verlos aunque esten ante nuestras 
narices. Por ahora no vamos a estudiar 
las sentencias que nos permiten crear 
nuestras propias texturas y vamos a li- 
mitarnos a senalar que «POV» ya trae 
incorporada una gran 
libren'a de texturas 
para que podamos 
crear objetos con apa- 
riencia de madera, 
agua, piedra, cristal, 
metales, etc. Estas 
texturas predefini- 
das estan almacena- 
das en los ficheros 
woods.inc, stones.inc, 
metals.inc, glass.inc y 
otros que encontrare- 
mos en el subdirecto- 
rio llamado "include", 
dentro del directorio 
donde tengamos a 
«POV». Estas textu- 
ras estan creadas con 
#declare y asignadas 
a identificadores, 



Figura 4 



por lo que para utilizarlas nos bastara 
con emplear la sentencia texture escri- 
biendo dentro el nombre del identifi- 
cador. En ciertos casos, no obstante, 
puede ser necesario algo mas. Si por 
ejemplo estamos asignando una textu- 
ra de madera a un objeto, los resulta- 
dos dependeran en gran medida de la 
escala del objeto con respecto a la tex- 
tura. Asi', si el objeto resulta demasia- 
do grande con respecto a la escala a la 
que se han definido los detalles de la 
textura, puede suceder que no perci- 
bamos dichos detalles al observar al 
objeto. Para remediar esto bastara con 
escribir una sentencia de escalacion 
dentro del bloque de la textura. Asi, 
por ejemplo, la sentencia: 

object(head texture (T_Wood28 
scale<2,2,2>}} 

hace que la textura se aplique a una 
escala dos veces mayor de lo normal 
sobre el objeto head. Naturalmente es- 
to es posible solo porque, siguiendo 
las reglas del ambito de los bloques, 
la operacion de escala afecta solo a la 
textura y no al objeto. Este conservara 
el tamafio que tuviese pero los deta- 
lles de la textura pasaran a ser dos ve- 
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ces mas grandes. Quiza, observando 
la sentencia os pregunteis por que he- 
mos hecho que la escala se efectue en 
los tres ejes y la respuesta es que 
T_Wood28 es una textura procedural 
normal de «POV» (definidaen woods.inc 
con sentencias normales del lenguaje 
escenico, como las demas). Esto sig- 
nifica que, como todas las demas tex- 
turas algorftmicas de nuestro amado 
raytracer, ocupa un volumen infmito 
en todas direcciones. 

Esto quiza parezca raro a los render- 
manfacos que solo hayan trabajado 
con las tipicas texturas tipo bitmap, 
pero es asi. En «POV» las texturas 
procedurales son como volumenes tri- 
dimensionales que ocupan todo el 
universo espacial del programa. 
Cuando se declara un objeto dado en 
una posicion espacial y se le asigna 
una de estas texturas, el objeto queda 



"impregnado" con el dibujo 3D que la 
textura tenga en esa posicion. Para 
comprenderlo echad un vistazo a las 
dos escenitas de prueba. En la primera 
de ellas tenemos una esfera con una tex- 
tura de madera tomada de woods.inc 
y en la siguiente tenemos a la misma 
esfera a la que se le ha cortado la mi- 
tad superior. El interior de la esfera 
tambien tiene la textura aplicada. 
(otros programas como «Imagine» o 
«3D Studio» tambien tienen sus pro- 
pias texturas procedurales pero la 
gente casi nunca las usa, prefiriendo 
emplear bitmaps). 

A estas alturas os habreis dado 
cuenta de que tendremos que escribir 
una sentencia #include para cargar el 
fichero woods.inc antes de referenciar 
a la textura T_Wood28. Si no lo hace- 
mos asi, «POV» nos dara un mensaje 
de error y la escena no se generara. 



(La practica usual en estos casos es 
colocar todos los #includes al princi- 
pio del fichero escenico). Pero ademas 
de esto hay que hacer una cosa mas, 
hemos de indicarle a «POV» donde es- 
tan los ficheros. Por defecto, la orden 
#include busca los archivos que debe 
cargar en el directorio en curso pero 
puede suceder, como ocurre con los fi- 
cheros de texturas de «POV», que los 
archivos referenciados esten en otra 
parte. En estos casos «POV» seguira 
buscando en los directorios que le ha- 
yamos indicado con el comando "L" 
de la linea de ordenes (mas adelante 
veremos como funciona). 

Por otro lado, «POV» tambien tie- 
ne definida una buena lista de colores 
que hallareis declarados en colors. inc. 
Para usarlos linicamente tendremos 
que escribir el identificador del color 
dentro de la sentencia pigment. Pero, 




En esta escena hemos empleado el mismo fichero que se utilizo para la imagen de portada de Rendermania 14. 
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por supuesto, no tenemos por que res- 
tringirnos al uso de esta lista de colo- 
res. Podemos crear nuestros propios 
colores usando sentencias como: 

pigment (color rgb< 1 ,0,0> ) 

o como: 

pigmentf rgb<l ,0,0> } 

En ambos casos se crea un pigmen- 
to rojo gracias a la sentencia RGB, la 
cual emplea valores que pueden osci- 
lar de a 1 para asignar intensidades 
a los componentes de rojo, verde y 




Cada valor aleatorio genera una 
variacion en la postura basica. 

azul con los que se definen los colores 
en el pov-mundo. El valor corres- 
ponde a la minima intensidad y el 1 a 
la maxima posible. Los valores de es- 
tos componentes se complementan pa- 
ra producir todos los colores posibles. 
Asi, por ejemplo, "RGB<1,0.48.0>" 
crea un color naranja, "RGB<1.1,1>" 
crea el color bianco, etc. 

En fin, para acabar este resumen di- 
remos que «POV» incluye algunos fi- 
cheros de ejemplo que muestran el re- 
sultado visual que ofrecen las texturas 




El mismo valor de semilla genera identica 
personajes, como podeis apreciar en 



postura para ambos 
estas imageries. 



de su librerfa. Estos archivos estan lo- 
calizables en diversos subdirectorios 
del directorio texsamps (el cual, claro 
esta, se halla dentro del directorio raiz 
donde hayais metido «POV»). 

Algunas ordenes de la linea 
de comandos 

Para generar las imagenes correspon- 
dientes a los archivos mencionados an- 
tes o para crear alguna de las muchas 
escenas de ejemplo que incluye «POV», 
mas valdra que hablemos de las orde- 
nes de linea mas utilizadas que admite 
la version MS-DOS de «POV». Estos 
comandos afectan a la forma en que tra- 
baja «POV» y al fichero de salida con 
la escena que debe generarse. Por regla 
general suelen ir precedidos por un ca- 
racter + o -. El primero significa que la 
orden que le sigue se va a activar y el 
otro implica lo contrario. Los comandos 
deben escribkse en cualquier orden des- 
pues de invocar al programa. 

+1 se usa para indicar el fichero es- 
c^nico que «POV» debe procesar. 

+0 se emplea para indicar a «POV» 
el nombre que va a tener el archivo dc 
salida. 



+W indica la resolucion horizontal 
de la imagen a generar. 

+H indica la resolucion vertical. 

+D se usa para activar la visualiza- 
cion del modo grafico mediante el 
cual podremos ir viendo como «POV» 
genera las imagenes linea a linea. Este 
comando acepta dos parametros que 
se especifican con letras que deben co- 
locarse juntas. La primera sirve para 
indicar el tipo de tarjeta grafica dispo- 
nible o para ordenar el empleo del es- 
tandar VESA (letra "G") y la segunda 
senala el tipo de paleta. Normalmente 
solemos utilizar las letras H (Hicolor) 
o T (Truecolor). A veces puede conve- 
ftir desactivar la salida de video, lo que 
haremos con -D. 

+X Permite interrumpir la genera- 
cion de la imagen pulsando una tecla. 

+C Si interrumpimos la creacion de 
una imagen podemos reanudar poste- 
riormente el calculo sin perder las li- 
nens ya generadas usando +C. 

+P Esta orden obliga a «POV» a es- 
perar hasta que se pulse una tecla una 
vez que ha concluido la generacion de 
la imagen. Se usa con +D para ver las 
imagenes. Bk 
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camera (location 


<5900, 195, 0> 




direction 


<0.0, 0.0, 1> 




up <0.0 


1.0, 0.0> 




right <. 72, 0.0, 0.0> 




look_at < 


0,70.5,0> 


// 
} 


orthographic 


Figura S 



+V Cuando hemos de desconectar la 
salida de video es util emplear +v para 
que «POV» vaya imprimiendo el mi- 
mero de lfnea con el que esta trabajan- 
do en cada momento para hacernos una 
idea del tiempo que queda de render. 

+A Activa el antialias. Normalmen- 
te suele anadirse un valor que indica 
la fuerza del antialias (el valor por de- 
fecto es 0). Esto se usa para suavizar 
la apariencia escalonada que tienen 
las h'neas diagonales en la imagen. 

+L Con esta opcion podremos in- 
cluir una ruta al directorio donde ten- 
gamos ficheros .inc a los que vayamos 
a referenciar con #include desde el fi- 
chero escenico que se vaya a procesar. 

+B Cada vez que se termina una lf- 
nea «POV» hace una grabacion a dis- 
co a menos que usemos +B para redu- 
cir el niimero de accesos al disco 
duro. Junto a +B anadiremos un valor 
que sera el niimero de Kbytes que ten- 
dra el buffer de grabacion. La pega de 
esto es que si se va la luz o sucede un 
desastre habremos perdido todo lo 
que haya en el buffer. 

Por ultimo adjuntamos aqui la h'nea 
de ordenes que solemos utilizar (den- 
tro de un fichero Bat). 

povray +ibatalla.pov +obatalla.tga 
+dGH +x -v +p +w800 +h600 +a 
+bl92 +lc:\pov302\include 



Entre otras cosas, esta lfnea hara 
que «POV» genere el archivo bata- 
11a. tga a partir del fichero .pov del 
mismo nombre. Se activara la visua- 
lizacion usando el estandar VESA y 
Hicolor, se desactivara la estadfstica 
de lineas (con -v, esto es preciso si la 
visualization esta activada), se creara 
un buffer de grabacion de 192 Kbytes 
y se indica con +L una ruta para bus- 
car los archivos .inc. Tambien se em- 
plea el antialias estandar. 

La camara 

La camara de POV es similar a la de 
otros programas de imagen sintetica, 
es decir, una camara no visible que 
POV emplea para tomar una foto del 
universo virtual descrito en el archivo 
escenico suministrado como entrada 
al programa. Por esta razon todos los 
ficheros escenicos deben incluir una 
description de una camara valida uti- 
lizando las sentencias reservadas para 
ello en el lenguaje de POV. De lo con- 
trario, y al igual que sucedera si no hay 
objetos o fuentes de luz definidas en la 
escena, no obtendremos otra cosa que 
una imagen con un fondo negro. 

Por supuesto, podrfamos evitarnos 
el estudio del manejo de la pov-cama- 
ra si nos limitasemos a emplear pro- 
gramas como «Rhino» o herramientas 
de traduction como 3ds2pov (sin tra- 
bajar la escena despues desde POV), 
ya que, recordemos, estos programas 
graban en el fichero escenico expor- 
tado una camara equivalente a la em- 
pleada desde «Rhino» o «3D Studio*. 
Pero si verdaderamente deseamos uti- 
lizar las capacidades de POV nos ve- 
remos obligados a colocar la camara 
desde el lenguaje escenico. Esta tarea 
puede ser, no nos enganemos, bastan- 




El caballero emplea piezas 
intercambiables. 

te trabajosa e ingrata comparada con 
el rapido manejo de la camara que nos 
ofrece cualquier buen modelador. En 
efecto, a menudo nos resultara diffcil 
predecir la imagen que se obtendra de 
la colocacion de una camara determi- 
nada o el campo visual que abarcara 
esta, y ello nos obligara a realizar bas- 
tantes pruebas. 

Las sentencias que definen la cama- 
ra suelen ir colocadas casi al principio 
del fichero escenico, despues de los 
#includes, aunque pueden ser escritas 
en cualquier otra parte del archivo. En 
la Figura 5 tenemos la camara emple- 
ada para la escena de la portada. 

Las sentencias que definen a la ca- 
mara han de seguir a la sentencia "ca- 



#include "colors. inc" • 
camera { £ 




location <0, 0, 0> £ 




direction <0,0 ,1> 




up <0.0, 1.0, 0.0> 


} 


right <1.33,0.0, 0.0> 


light 


_source (<0,0,0> color White} 


sphere{<0,0,5>,l pigment(Green)} 


sphe 


re{<0,0,-5>,l pigment{Blue}} 
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En la imagen se aprecia el momento de ajustar las dimensiones 
caballero a las del orco. 



del 



mera" y estar englobadas por corche- 
tes, aunque no tienen por que seguir 
el mismo orden que aparece en esta fi- 
gura. La primera de ellas, "location". 
se utiliza para indicar -dando valores 
para los ejes X, Y y Z- la posicion es- 
pacial de la camara. Luego, para en- 
focar a esta, deberemos emplear la 
sentencia "Look_at" (mirar a), con la 
que indicaremos el punto espacial ha- 
cia el que queremos apuntar la cama- 
ra. Al hallar esta sentencia, POV hara 
girar la camara a la derecha o la iz- 
quierda y la inclinara hasta que el 
punto a enfocar quede apuntado por 
la camara. 

Llegados aqui se hace necesario ex- 
plicar un par de puntos. La camara no 
es un objeto solido ni tiene dimensio- 
nes, pero debemos imaginar que, co- 
mo en el caso de las camaras reales, 
tiene una lente a la que llamaremos 
"ventana de vision". Esta ventana de 
vision tiene forma rectangular y sus 
caracteristicas son controladas por las 
sentencias "direction", "up" y "right", 
las cuales controlan tambien el campo 



visual que abarca la mencionada ven- 
tana de vision. Direction define la di- 
reccion inicial hacia la que apunta la 
camara. Asi, por ejemplo, la senten- 
cia direction "<0.0, 0.0, 1>" del ejem- 
plo significa que la camara inicial- 
mente esta mirando en la direccion 
+Z. El valor 1 tambien significa que 
la lente se encuentra a una unidad de 
distancia de la posicion base de la ca- 
mara y esto determina -junto con el 
valor de up- el tamano de la ventana 
de vision. 

Para comprenderlo dibujad en una 
hoja un punto para representar la po- 
sicion base de la camara y tambien 
una lfnea vertical a la derecha del 
punto anterior (la linea ha de estar 
centrada verticalmente con respecto a 
dicho punto). Si ahora trazais dos lf- 
neas que conecten el punto con los 
dos extremos de la linea vertical po- 
dreis visualizar el perfil de una cama- 
ra ti'pica de POV, donde la apertura 
del campo de vision depende de la 
distancia de la ventana de vision (la 
linea) con respecto a la posicion de la 



camara (el punto). Observareis que si 
arrastrais la linea vertical a la derecha 
las dos lineas diagonales (que repre- 
sentan el campo de vision de la cama- 
ra) formaran un angulo menor entre si. 
Traduciendo este ejemplo a POV, sig- 
nifica que un valor corto de direction 
implica un campo de vision mayor y 
un valor largo lo contrario. Fijaos en 
la Figura 6. 

En el ejemplo no hay sentencia look_at. 
La camara mira en la direccion +Z de ma- 
nera que, al renderizar la escena, con- 
templaremos una esfera verde (green) 
en el centra de la escena. Aqui la len- 
te de la camara se encuentra a una 
unidad de distancia de la camara. Si 
ahora cambiamos el 1 de direction por 
un 2 y volvemos a realizar la prueba 
la esfera sera dos veces mayor. Esto 
se debe a que hemos alejado la venta- 
na de vision de la camara reduciendo 
el campo de vision, lo cual se aprecia 
como un zoom realizado sobre la di- 
reccion enfocada. (Si se sustituye el 1 
por - 1 la camara apuntara a -Z y vere- 
mos la esfera azul). 

En cuanto a las sentencias up y 
right, estas controlan las proporciones 
de la ventana de vision, la orientacion 
del sistema de coordenadas (right) y 
la direccion vertical de la ventana de 
vision (up). El valor 1.33 de right sig- 
nifica, por ejemplo, que la imagen va 
a ser un 1.33 mas ancha que alta. Es 
decir, que vamos a ordenar con +w y 
+h una resolucion como 640*480 6 
800*600 por ejemplo. En cambio, pa- 
ra generar una imagen de 1024 de alto 
por 768 de alto, el valor de right debe- 
rfa ser de .72. (Nota: raramente toca- 
mos up y solamente cambiamos right 
cuando vamos a lanzar escenas con 
distintos formatos. Es peligroso cam- 
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Hemos creado un nuevo soldado con Rhinoceros. 



biar right a negativo porque uno puede 
volverse loco si esta acostumbrado al 
sisteraa "normal" de "mano izquierda" 
que utilizamos aqui. Casi siempre 
suele bastar con trastear con location 
y look_at. ;Ojo! Poned siempre la 
sentencia look_at despues de las de- 
mas ya mencionadas). 

Tipos de camara 

En el primer ejemplo habia una sen- 
tencia llamada "orthographic" anula- 
da por un comentario. Esta sentencia 
cambiaba el tipo de perspectiva por 
defecto por otra en la que los rayos 
son paralelos. Este tipo de camara sin 
perspectiva es muy litil cuando se 
quieren realizar pruebas de estimacion 
de distancias o estamos estudiando las 
formas de un objeto y no queremos ser 
enganados por la perspectiva. 

Aparte de orthographic existen 
otros tipos de camara como fisheye 
(ojo de pez), omnimax, panoramic y 
cylindrical. Para comprobar su fun- 
cionamiento solo teneis que incluir la 
palabra correspondiente al final de las 



sentencias de la camara. Y, por su- 
puesto, tambien podemos crear nues- 
tra propia camara utilizando senten- 
cias como angle. 

Fuentes de luz 

Para concluir con la pequena intro- 
duccion que estamos realizando sobre 
«POV» vamos a tratar brevemente el 
tema de la luz. 

«POV» dispone de varios tipos de 
fuentes: ambientales, omnidirecciona- 
les, focos, cilindricas y areas de luz, 
y tambien cuenta con diversas posibi- 
lidades de control sobre estas fuentes. 
Sin embargo, nos limitaremos a ha- 
blar del tipo de fuente mas sencilla y 
utilizada: la omnidireccional. El nom- 
bre de esta fuente se debe a que sus 
rayos parten en todas direcciones (co- 
mo en el caso del sol o de una bombi- 
11a). Veamos su formato: 

light_source { <0,0,0> color White } 

Esta sentencia crea una fuente de 
luz omnidireccional de color bianco 



en las coordenadas <0,0,0>. El forma- 
to de la sentencia es, pues, muy senci- 
llo. Primero incluimos la sentencia y 
dentro de los corchetes delimitadores 
colocamos, primero, las coordenadas 
de posicion y luego el color de la 
fuente. Podemos indicar dicho color 
como en el caso anterior o emplean- 
do la sentencia "RGB" que ya vimos 
con los pigmentos: 

light_source (<0,0,0> color rgb<l,l,l>} 

Normalmente basta con una o dos 
fuentes de este tipo para iluminar 
cualquier escena -ninguna de las ima- 
genes del presente numero ha requeri- 
do mas de dos fuentes-. Las fuentes 
de luz de «POV» son puntuales, es de- 
cir, todos los rayos que emiten parten 
del mismo punto. Esto implica dos 
cosas: la primera que no son visibles 
(aunque existe una manera de crear 
objetos que simulan ser luminosos) y 
la segunda que las sombras que gene- 
ran tienen bordes excesivamente pre- 
cisos y que por ello resultan bastante 
irreales (lo cual se puede solucionar 
utilizando areas de luz). 

Una buena iluminacion es capital 
para lograr buenas e interesantes es- 
cenas. Si estais trabajando sobre una 
imagen de tipo "a cielo abierto" lo 
mejor es situar las fuentes de luz a 
distancias astronomicas para que las 
sombras de todos los objetos tengan 
una orientacion identica. Tambien 
suele ser buena idea utilizar fuentes 
de colores distintos para crear algo de 
contraste y emplear areas de luz si nos 
sobra tiempo (cada vez que sumemos 
una fuente a la escena estaremos au- 
mentando el tiempo de calculo nece- 
sario para generarla). 
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iLabatalla 

de la gran llanura! 

El caballero se inclino sobre la barandilla y miro hacia el suelo: a cientos 
de metros bajo sus pies se extendia un inmenso ejercito. Arrugo la nariz y 
ordeno al oficial de navegacion que pusiera rumbo al castillo. Con suerte 
el dirigible de exploracion que mandaba llegaria al feudo a tiempo de 
prevenir al senor de aquella nueva invasion orca. Mientras el dirigible 
giraba lentamente, el caballero siguio observando con una sonrisa en los 
labios. jSin duda se avecindaba una dura y estimulante batalla! 



espues de esperar 
durante meses el 
gran acontecimien- 
to, estamos prepa- 
rados para disfrutar 
de una batalla orco- 
humana digna de este nombre. Cien- 
tos de bestiales guerreros orcos han 
chocado contra las tropas humanas en 
un enfrentamiento largamente poster- 
gado. Ambos bandos han empleado al- 
gunas de las maquinas de guerra que 
enviasteis para apoyarles, y por ello la 
lucha ha sido verdaderamente feroz. A 
continuation os comentamos los defa- 
lks de este magno acontecimiento 

El origen de la batalla 

Todo empezo hace mucho tiempo 
con el ntimero 1 de Rendermania, 
cuando creamos unos lanceros bas- 
tante ridiculos para poblar el castillo 
virtual que ilustro aquel numero. En 
ese mismo numero un autor publico 
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un orco de aspecto bastante feroz y 
nos comento que sin duda su criaturi- 
11a virtual podn'a hacer trizas sin pro- 
bleraas a los diminutos lanceros. Algo 
picados, decidimos reforzar a los lan- 
ceros con un canon que aparecio en el 
numero 2 de Rendermanfa, y a partir 
de aqui dio comienzo una inacabable 
carrera de armamentos. 

Asi, comenzasteis a enviar modelos 
de maquinas de guerra para apoyar a 
uno u otro bando y pronto la idea de 
crear una portada con una batalla me- 
dieval fantastica como tema surgio sin 
remedio. Se pretendi'a crear una esce- 
na con cientos de guerreros donde 
apareciesen las catapultas y las demas 
maquinas de guerra enviadas por los 
lectores. 

Sin embargo, pasaron los meses y la 
batalla no parecia tomar forma en las 
paginas de Rendermanfa. Finalmente, 
en el numero 9 del suplemento, se pu- 
blico una portada donde aparecfan 
tres parejas de contendientes (jsolo 
3!) peleandose sobre una superficie 
llena de libros. Esto fue decepcionan- 
te, por supuesto, pero al menos sirvio 
como base para estudiar los dos pro- 
blemas principales que presentaba el 
diseiio de este tipo de escenas: 

• Los modelos eran mallas poligo- 
nales y cada personaje requen'a mu- 
cha RAM. 

• No se disponia de un modelo arti- 
culado de orco; entonces se empleo 
un zombie en su lugar. 

En el numero 9 estos problemas no 
pudieron ser solucionados a tiempo 
pero no queriendo hacer esperar mas a 
los lectores, se decidio emplear algu- 
nos de los modelos enviados para 
componer una portada. Al menos este 
numero sirvio para comprobar lo sen- 



cillo que resultaba crear 
posturas de modelos con 
«lmagine» y como expor- 
tar modelos poligonales a 
«POV». 

Sin embargo, pronto 
empezaron a resolverse 
los problemas que hacian 
imposible la ansiada bata- 
lla. Primero se creo un 
modelo articulable de or- 
co en el numero 1 1 em- 
pleando «Rhinoceros» y 
luego, en el numero 12, se 
anadieron un par de cabe- 
zas mas de orco. Final- 
mente descubrimos el uso 
de mesh y poco tiempo 
despues esta sentencia fue 
empleada para crear el 
ejercito de orcos que apa- 
recio en el numero 14 de 
Rendermanfa. A partir de 
aquf solo era cuestion de tiempo pre- 
parer nuestra primera batalla virtual. 

El bando humano 

El primer paso una vez resueltos los 
problemas principales era contar con 
modelos adecuados para la batalla. El 
modelo del orco podfa servir a pesar de 
sus fallos de articulacion pero no ocu- 
rrfa lo mismo con el viejo lancero. Este 
resultaba ya algo simplon comparado 
con el orco y se necesitaba otro mode- 
lo de aspecto mas realista. 

Por esta razon se ha creado un nuevo 
modelo de soldado que conserva, sin 
embargo, un cierto aire de familia con 
nuestro antiguo lancero, del que solo 
hemos tornado las manos y el casco 
para el nuevo soldado. 

En principio la idea era crear una ar- 
madura completa pero pronto se opto 




por crear tambien piezas internas para 
el cuerpo. De esta manera se podfan 
eliminar trozos de armadura y crear 
una mayor variacion. Asi, en las esce- 
nas que ilustran el presente numero, 
hay soldados con y sin protection en 
las piernas (lo que se controla desde 
los ficheros escenicos gracias a una va- 
riable). Esto queda bastante bien por- 
que las piezas empleadas para el cuer- 
po del soldado han sido tomadas del 
cuerpo del orco. Naturalmente fue pre- 
ciso editar grupos de vertices para lo- 
grar que el soldado resultase menos 
musculoso que el orco. 

Pero la falta de tiempo hizo imposible 
llevar esta idea hasta sus ultimas con- 
secuencias y por ello nuestro soldado 
no tiene cabeza bajo el casco ni puede 
quitarse atin las protecciones de los 
brazos al no estar recortado el peto. 
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Tambien hay que decir que nuestro 
soldado tiene fallos de articulation. Es- 
tos fallos son de dificil solution. Cuan- 
do, por ejemplo, el soldado levanta una 
pierna, esta corta el faldon metalico de 
la armadura. Ademas, las hombreras 
pueden interseccionarse con el brazo si 
este se coloca en una posicion excesi- 
vamente forzada, y lo misrao sucede 
con la placa del codo. 

Al constatar esto, se probo, en pri- 
mer lugar, que estos objetos rotasen 
acompafiando el movimiento de las 
piezas de la armadura a que estaban 
unidas, pero el resultado era visual- 
mente muy confuso, por lo que se opto 
por dejarlas sin movimiento. 

Finalmente. con el fin de obtener al- 
go de variedad, se crearon varias pie- 
zas adicionales: un segundo escudo, un 
par de cascos mas y otra hombrera. De 



esta manera se confiaba 
en obtener soldados bas- 
tante diferentes entre si. 
Pero, como siempre, la 
falta de tiempo impidio 
disponer de todas las pie- 
zas que hubiesen sido ne- 
cesarias para que esta idea 
I uncionase de verdad. Ha- 
bn'a sido conveniente dis- 
poner de un par de petos 
mas, de varias piezas in- 
tercambiables para brazos 
y piernas, de un fald6n di- 
ferente, etc. 

Preparation de las 
posturas 

En principio la idea era 
tomar nota desde «Imagi- 
ne» de los angulos de ro- 
tation deseados para 
aplicarlos luego desde 
«POV», tal y como se hizo con las 
posturas creadas para el numero 14. 
Pero pronto se comprobo que esto ya 
no era necesario. 

En efecto, despues de unas cuantas 
pruebas la experiencia hizo posible 
escoger a mano los valores medios de 
rotation para las posturas de correr, 
golpear, defender y estar muerto. De 
esta manera, tan solo fue preciso es- 
cribir los ficheros .pov e .inc necesa- 
rios. Aquf se comprobo que, como el 
esquema de articulaciones de ambos 
modelos era similar, los dos podi'an 
compartir los mismos ficheros inc de 
posturas, lo que permitio un significa- 
tivo ahorro de trabajo. 

Naturalmente esto fue posible por- 
que se emplearon los mismos nom- 
bres para las variables de rotacion en 
orco.inc y guerrero.inc. Por esta ra- 



zon, ambos modelos pueden utiliznr 
indistintamente los ficheros orcan- 
da.inc, correr.inc, golpear.inc y otros. 
Para quienes deseeis saber con mas 
detalle como funciona esto os reco- 
mendamos leer el numero 14 de Ren- 
dermania, pues el proceso seguido es- 
te mes es el mismo. En resumen: 

• Se crean los modelos desde un 
modelador poligonal cualquiera. 

• Se toma nota desde el mismo mo- 
delador de las coordenadas de los ejes 
de rotacion de cada pieza. Estos valo- 
res seran empleados luego en los fi- 
cheros .pov que definen la jerarquia 
de los modelos. 

• Se graba cada pieza del modelo in- 
dividualmente (exportandolas directa- 
mente a «POV» si el modelador lo 
permite o usando despues una utilidad 
de traduction). 

• Se escriben primero los ficheros 
de jerarqufa (como orco.inc y guerre- 
ro.inc) y luego los que guardan los va- 
lores medios de rotacion para obtener 
las posturas. (Estos son correr.inc, 
golpear.inc, etc). Los ficheros de je- 
rarquia referencian a los ficheros .inc 
que guardan las mallas y hacen girar 
cada pieza o grupo de piezas segiin 
los valores de rotacion suministrados 
por los archivos-postura. Ademas, los 
valores de rotacion que se suministran 
a los archivos-jerarquia suelen ser 
siempre diferentes ya que los archi- 
vos-postura utilizan rangos aleatorios 
de libertad de movimiento para cada 
postura basica. De esta manera resulta 
posible obtener desde «POV» un nu- 
mero infinite de posturas a partir de 
un modelo almacenado en una linica 
posicion inicial. 

• Despues se crean los ficheros .pov 
que definen las escenas y que em- 
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plean bucles #while con 
cientos de pasadas sobre los 
ficheros con las posturas (pri- 
mero) y los ficheros-jerarqufa 
(despues). Cada una de estas 
pasadas define un nuevo per- 
sonaje en la escena. 

Naiuralmente todo esto 
ha sido posible gracias a las 
caracten'sticas de sentencias 
del lenguaje escenico como 
#declare, #include, #while, 
#if y otras. Y tambien al 
hecho de que cada objeto 
copia utiliza una ridicula 
cantidad de memoria en 
comparacion a la que re- 
quiere el almacenamiento 
del modelo original al que 
se referencia con cada ob- 
jeto-mesh. 



La batalla y otras ideas 

Hemos preparado preferentemente 
escenas donde se ve a ambos ejercitos 
a punto de chocar. Aunque en princi- 
pio solamente se iba a preparar una 
portada, pronto quedo claro que la 
idea daba para mucho mas y se opto 
por crear muchas mas escenas. 

Esto resultaba tanto mas preciso por 
cuanto era imposible aprovechar to- 
dos vuestros modelos en una unica es- 
cena. De hecho, solo hemos empleado 
algunos de vuestros primeros mode- 
los, ya que no habfa tiempo de prepa- 
rarlos a todos. 

Asi, hemos empleado el dirigible 
humano de Toni Sole, el magni'fico 
tanque humano de vapor de Oscar Al- 
varez Diaz y la catapulta orca de Ju- 
lian Hierro. Pero, ni que decir tiene 
que habra nuevas contiendas entre or- 
cos y humanos y para celebrarlas uti- 




lizaremos otros modelos diferentes 
entre los que nos habeis enviado. 

Nota: nos hubiera gustado dar el 
mando de nuestros orcos a Ghorkas, 
el fantastico orco creado por Jose Luis 
Robledo Pescador. Pero la malla que 
envio no estaba entera -faltaban pie- 
zas en los brazos-. Jose Luis, si quie- 
res que tu modelo aparezca en una 
proxima edicion, por favor, envi'a una 
malla completa. 

En cada nueva edicion intentaremos 
preparar cosas nuevas. Y quiza algiin 
dfa estemos preparados para crear, 
ademas, una descomunal animacion 
con cientos de modelos corriendo o 
batallando entre si. 

Naturalmente todo esto tambien es 
aplicable a los mechs o a cuaiquier 
otro tema que se escoja como porta- 
da; ultimamente se ha hablado bastan- 
te de preparar escenas espaciales. 



En general se prepararan es- 
cenas de uno u otro tipo se- 
gun el niimero de modelos 
que hayais enviado, lo cual 
equivale tambien a enviar 
votos a favor de un tema da- 
do para que estudiemos si 
es posible o no llevarlo a la 
practica como protagonista 
de la portada. 

Las escenas 

Casi todo el presente niime- 
ro constituye una pequena 
introduccion a «POV», lo 
cual no guarda demasiada 
relacion con las ilustracio- 
nes empleadas. El motivo 
de esto, aparte por supuesto 
de nuestras ganas de pre- 
sentar por fin una contien- 
da virtual, es que una intro- 
duccion de este tipo solo requiere 
unas escenas muy sencillas que, esta- 
mos seguros, los lectores no necesi- 
taran para entender las explicaciones. 
En lugar de esto hemos preferido 
ilustrar Rendermania con estas esce- 
nas para mostrar lo que «POV» es ca- 
paz de hacer. 

NOTA: las escenas mas complejas han re- 
querido una media de 10 minulos de parsing 
(los ficheros .inc con las mallas tienen un ta- 
maho de unos 50 Megas) y de 20 a 60 minulos 
para ser renderizadas sobre un Pentium a 150 
MHz. iQuien dijo que «POV» es lento? 

NOTA: Porfalta de espacio, encontrareis 
dentro delfichero leedme.txt en el directorio 
Batalla dentro de la seccion Rendermania 
en el CD-ROM de la revista, las instruccio- 
nes oportunas para manejar los ficheros que 
adjuntamos. 



16 Rendermania 






El Foro del Lector 



Nota important! . Podeis remitimos vuestros trabajos o consultas, bien por carta a la direction que 
figura en el sumario de Pcmania, o via e-mail a rendennania.pcmania@hobbypress.es 

Preguntas, sugerencias 
y polemicas 

En este numero, como siempre, nuestro foro es la galena de siempre 
donde podreis hallar magnificas escenas y alguna que otra animacion. 
Sin embargo, este mes queremos hacer hincapie en el propio foro, es 
decir, en las cartas remitidas por los autores de estos trabajos. En ellas 
encontrareis descripciones de los procesos de creacion, preguntas (a las 
que no siempre podemos contestar por falta de espacio), propuestas 
interesantes y opiniones diversas. 




Este mes nuestra primera pagina del foro es para Roberto Gracia, el cual solo 

ha tardado unas dos semanas en crear su propio trasatlantico virtual. Aunque 

claramente ambientado en el "Titanic", el "Oriental" ha sido disefiado entera- 

mente por este autor, quien ha empleado «3D Studio 4» y «Spatch» para crear el 

monumental barco que podeis ver aqui. Sin embargo, el "Oriental" aiin no esta 

realmente listo para su botadura ya que, como cuenta el propio Roberto en su 

carta, aiin faltan hamacas, sillas y otros detalles. Algo que Roberto ya tiene pre- 

visto hacer en la animacion que espera preparar proximamente. 

Hay que descubrirse ante el resultado obtenido por Roberto. El barco es muy convincente, tiene una estructura fun- 

cional dividida en cubiertas (conectadas entre si con escaleras) y dispone tambien de los inevitables botes de salva- 

mento. Roberto incluso ha utilizado un modelo humano para comprobar la co- 

rrecta proporcion de todos los detalles del 

"Oriental". En fin, un barco de verdadero lu- 

jo por el que te enviamos nuestras mas sin- 

ceras felicitaciones. Confiamos que pronto 

podamos ver una animacion en la que nave- 

gue por esos mares virtuales. (Nota: mas de- 
talles en la carta de Roberto, en el foro). 
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Un grupo de rendermaniacos se ha unido para formar el 
grupo \STRO 3D con el encomiable proposito de crear 
una librerfa de objetos de libre uso. En su carta, Ifiuki Ka- 
rros -uno de los miembros de este grupo- solicita la co- 
laboracion de otros rendermaniacos y da su direccion y la 
direccion e-mail de otro de los miembros. (Ifiaki ha en- 

viado tambien las 
dos escenas espa- 
ciales que podeis 
ver aqui). Lo di- 
cho, una original 
iniciativa a la que 
deseamos el ma- 
yor de los exitos. 





Si quereis ver un buen 
combate espacial en- 
tre los inolvidables 
cazas rebeldes y los 
Tie imperiales echad 
un vistazo a la magnffica animacion remitida por 
Sergio Ruiz Navarro. Tanto esta como los mo- 
delos que aparecen en ella estan pero que muy 
bien (sobre todo para alguien que lleva poco 
tiempo en esto). La coreograffa de la batalla esta 
muy lograda y las escenas donde se ve la cara 
del piloto aportan simpatia y realismo. Sin em- 
bargo, sentimos decir que el primer disco de la 
serie llego mal y a causa de esto no hemos podi- 
do publicar los tftulos. 

En cuanto a tus preguntas. Para conocer las 
caracterfsticas del «MAX» te aconsejamos el li- 
bra publicado sobre este programa por Roberto 
Potenciano en Anaya. «POV», por otro lado, es 
un trazador de rayos que emplea un lenguaje pa- 
ra modelar en lugar de una interfaz grafica como 
la empleada por «3D Studio». No olvideis leer la 
carta de Sergio para poder ver la animacion. 




Francisco Javier Cruz Jimenez ha empleado a «Polyray» (el raytracer hermano de 
«POV») para crear su Castillo y a «POV» y «Moray» para levantar la estupenda iglesia 
virtual que podeis ver aqui'. Para la iglesia -que aun no 
esta completamente acabada- Francisco ha usado tam- 
bien los famosos flares de Nathan Kopp. Sus cartas, don- 
de describe el proceso de creacion de ambos edificios, son una lectura recomen- 
dable para cualquier pov-adicto. Hay que destacar la forma en que Francisco creo 
la montana y la integro con el Castillo y el truco, sencillo pero efectivo, utilizado 
para ganar tiempo con las pruebas de render. En resumen, un buen trabajo. 




18 Rendermania 




Como ya hemos dicho mas de una vez, la lectura de las cartas del fo- 
ro suele ser una fuente de satisfacciones para nosotros, pero esto no 
siempre es asf y como ejemplo de excepcion presentamos hoy la car- 
ta de Pedro J. Ladaria 1 Jnden, el cual nos ha enviado varias escenas 
creadas con «3D Studio». La pena que hemos sentido al leer tu carta 
no se debe a la decepcion que sufriste al ver la portada del numero 9 
(ya explicamos entonces por que no pudimos hacer algo mejor) ni 
por tus opiniones sobre «POV», ni tampoco por tus escenas (que nos 
han gustado bastante y cuya critica ya has hecho tu mismo). No, lo 
que nos ha fastidiado es el parrafo G de tu apartado de consejos: ^Co- 
mo puedes hablar asf de la piraterfa? Es cierto que mucha gente tiene 
versiones piratas de programas de render. Esto no es algo especial- 
mente danino porque se trata de aficionados que no van a dedicarse 
profesionalmente a la infografi'a o que van a aprender antes de dedi- 
carse legalmente a ella (y por tanto a comprar). Pero de comprender esto a recomendar la compra de CD piratas media un 
abismo. Nosotros hemos comprobado el dano que la piraterfa hace a la produccion de software. Sabemos que... 
1) No importa lo barato que pueda ser un programa. Existe un alto porcentaje de gente que siempre preferira hacerse con una 
copia pirata. (^Se sentiran mas listos asf?). 2) Hay muchos programadores de talento que se desaniman porque los beneficios 
de su duro trabajo no estan garantizados por culpa de la piraterfa. Y no nos referimos aquf a programas caros sino a otros que 
estan teoricamente al alcance de cualquier bolsillo y que bastante gente prefiere encontrar en alguno de esos CD piratas que 
mencionas. (Porque en ellos vienen muchos programas por el precio de uno. <,No?) 
Espero que recapacites sobre lo que has dicho y para terminar solo te diremos dos cosas: 

^.Cuanto habrfas tardado tu en renderizar una imagen como la del numero 14, por ejemplo? Con «POV» una imagen de este ti- 
po a 800*600 puede tardar de 30 a 45 minutos. La verdad es que sf sabemos algo de «MAX» pero las paginas de Rendermanfa 
estan dedicadas a programas share o free y a versiones libres de programas comerciales porque estan al alcance de todos. <,Y 
cuanto sabes tu de «POV» para hablar asf de el? 




Jordi y Albert son otro par de rendermaniacos adep- 
tos a «3D Studio 4» y a «MAX». Nos ha gustado el 
anuncio de la pasta dentffrica y tambien las originales 
escenas con las poses futbolfsticas. La camara, la luz y 
las texturas son correctas pero creemos que aun debe- 
rfais ejercitaros mas con el modelado. 



Felipe Canizares es un nuevo povmanfaco que tan solo 
llevaba dos semanas con «POV» cuando envio estas dos 
imagenes. Para el un 
par de consejos: 

1 ) El libro que tienes no 
trata de la version 3.0 
pero empollate como 
sea las sentencias de 
programacion de POV. 
jTus escenas ganaran 
muchoconellas! 

2) Procura emplear los 
efectos de «POV» solo cuando tengas listos todos los de- 
talles de la escena. Ganaras tiempo (y esto tambien va 
por las areas de luz, aunque no sean ningun efecto). 
Tomo nota de tu sugerencia de las ciudades futuristas y 
las batallas espaciales para las portadas. 
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De Mario Prats Sanchez nos llegan dos 
cartas. En la primera veremos al Arachno, 
un original mech en forma de arana prepara- 
do para todas las vicisitudes de la guerra vir- 
tual moderna. EI modelo creado con Imagi- 
ne y renderizado desde POV ha llegado 
demasiado tarde para la primera portada de 
mechs pero no temas. jHabra mas! Arach- 
no nos ha gustado mucho y tan solo cambia- 
n'a la forma de los pies y el valor de reflec- 
tion, el cual nos parece alto. En cuanto a lo 
que dices de la memoria. no hay forma de 
saber a priori el tamano que tendra el .inc 
resultante de una conversion pero si de saber 
la cantidad de RAM que usa «POV», ya que 
te lo dice el propio programa en la pantalla 
de estadfsticas al acabar el render. 

En su segunda carta (en el directorio se- 
gunda) Mario nos cuenta su paso a «MAX» 
y nos envi'a escenas con un Castillo que pa- 
rece de juguete. Esto se debe a la textura 
empleada y a la simplificacion de algunos 
detalles. Por ello creemos que las escenas. 
resultonas gracias a las multiples luces, ha- 
brfan ganado si hubieras puesto el Castillo 
sobre una mesa con otros juguetes, aunque 
esta idea tampoco es muy original. 
Por ultimo, pasaremos tu sugerencia sobre 
los plug-ins a redaccion. 






Antonio Rodriguez Gregores nos envfa un estupendo Mech cre- 
ado con «MAX» e «Imagine». Antonio ha enviado al Nayi 001-fx 
desglosado en partes para que nos sea mas facil prepararlo para 
«POV» con vistas a la portada de mechs (;gracias. lo utilizare- 
mos!) y tambien apunta una estupenda idea, que los propios lec- 
tores creen sus propias batallitas empleando mechs de otros auto- 
res. Asi, en cada enfrentamiento, cada parte podria realizar una 
escena con su mech y el del contrincante, ganando el autor que 
hubiese preparado la escena mas resultona. De momenta Antonio 
ha desafiado ya a los her- 
manos Oscar y Alberto 
Otero Leal y a Benjamin 
Albares Moreno. ^Al- 
guien recoge el guante? 
En cuanto al Nayi, se 
trata de un buen modelo 
al que quiza le falte un 
poco de detalle. Nos ha 
gustado mas tu escena 
habit.jpg, que es una de 

las mejores habitaciones virtuales que han pasado por aquf (por 
la luz, las texturas, la disposicion del cuarto. etc.) 




Raul Gomez Cardoso nos ha enviado unas simpaticas criaturi- 
llas virtuales creadas con «3D Studio 4». Por un lado esta un or- 
co-ogro y por otro una especie de alien-perro. Bien, no vamos a 
criticar tu obra pero te daremos un par de consejillos: 
1 ) Hasta que no tengas mas practica en el modelado de formas 
organicas procura que tus modelos antropomorficos queden me- 
nos desnudos. Podrfas. por ejemplo, haberle puesto una armadu- 

ra al orco con lo cual 
habrias obviado la rea- 
lizacion de ciertas par- 
tes dificiles. La verdad 
es que el cuerpo de tu 
modelo parece casi una 
armadura. Tan solo ha- 
brias tenido que cam- 
biar el color verde del 
cuerpo y afiadir algunas piezas mas para que pareciese que el 
monstruo estaba dentro de una armadura. 2) Respecto a tus difi- 
cultades con «3D Studio 4» te recomendamos que te compres al- 
giin libro sobre el tema. Te ahorraras muchos sufrimientos. 
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